Skip to main content

2.3 Advanced

Databases​

Before you deploy the Blink server, you need a Postgres and a Redis database. By default, you can pass the Postgres connection string via DATABASE_URL environment variable, and the Redis connection string via REDIS_URL environment variable.

Please see the docker-compose.yml of the repo to see a working setup running on docker-compose.

danger

MySQL is not currently supported as Blink relies on some PostgreSQL-specific features/isn't tested on MySQL. We hope to add MySQL support in the future, but for now, a recent-ish version of PostgreSQL is required.

Database Migrations​

For both the docker and bare metal installations, Blink will automatically run database migrations (see AUTO_MIGRATE=1 in the .env for why it's doing so), so you don't need a "release" step or anything - just spin it up and you're good to go!

If you'd like to manually run migrations and prevent Blink from running it before actually spinning up the server, please set the environment variable AUTO_MIGRATE=0.

Deploying to Your Own Server​

A few commonalities to keep in mind no matter how you're running the Blink server (most of these are standard 12-factor app practices):

  • The process pipes logs to STDOUT/STDERR in json format, so your environment (whether it be Kubernetes or just a simple pipe to files) should handle the logs coming off of STDOUT/STDERR.
  • Database migrations need to run before running the server in order to set up the DB. Furthermore, every time you update the app, you should run npm run db:migrate in order to keep the database's structure up-to-date.
  • The server is only exported as a singular process - no process wrappers, or anything of the sort. That means that your environment must support running the app in a resilient way, whether it is running the Docker container to restart on failure, running the container as part of a greater orchestration system, or running the process using pm2/systemd.
  • The server is a stateless process; therefore, you may kill it however much you'd like (especially given that it is expected for the CDN to cache basically all requests)
  • This also means there's no trouble clustering/running multiple instances of the server (though it really shouldn't be necessary): just spin multiple instances up and load balance across the instances.
  • You can specify the port that the server runs on using the $PORT environment variable. Otherwise, it will run on port 3000 by default.
  • The server itself does not speak HTTPS; rather, it exposes its API and UI via http, and expects a reverse proxy to terminate the SSL and forward the entire Blink domain/subdomain to the process.
note

Please see the Configuration page to learn how to configure these variables - below I'm just passing them manually for simplicity's sake!

Docker​

Blink is provided as a Docker container! Just pull the image, connect it to your SSO/CDN as described in the previous sections (this means you need to have already set up all of the requisite environment variables properly - whether through -e flags, .env files or otherwise), and connect it to your postgres/redis instances:

docker pull ghcr.io/janejeon/blink:latest
docker run (insert docker options here) \
    ghcr.io/janejeon/blink:latest npm run db:migrate
docker run (insert docker options here) \
    ghcr.io/janejeon/blink:latest
note

The docker image is hosted at https://ghcr.io/janejeon/blink, but take care to pin the image version with the following tags (by default, it will use the latest tag):

  • nightly tracks the master branch, and is cut every night after passing all automated tests
  • latest tracks the latest branch that was released manually (by me, after testing)
  • vX tracks the major releases of Blink, and is updated for every minor release within the vX major release.
  • vX.Y tracks the minor releases of Blink, and is updated for every patch release within the vX.Y minor release.
  • vX.Y.Z tracks the patch releases of Blink. These tags are immutable, so they do not update for any release.

Bare Metal​

Clone the repo on your server, then like above, configure the .env (or .env.production or .env.production.local) file.

Then, it's just a couple of steps to run:

export NODE_ENV=production
npm i -P && \
    npm run build && \
    npm run db:migrate && \
    node bin/www

Note that we only support node LTS versions, so if you're expecting difficulties, try using the LTS build.

Advanced Analytics​

See the Architecture page for advanced edge/server access log-based analytics!